The rapid evolution of computer and communication technologies coupled with the robust economies of the 1980s and 1990s resulted in unprecedented growth in the information technology field. In a growth economy, the need to establish a competitive advantage drove companies to faster and faster rates of change to support new product offerings and expanded services. As a result of these market pressures and time constraints, many companies elected to support new products and services by adding additional back office systems. However, due to the lack of mature integration technologies, the new systems were connected to the existing IT systems by making direct connections to the software routines already in use. The vulnerability of this design is that a change in one system precipitates a “ripple effect” change in every system it connects with. Over time, this incremental stacking of software systems can result in an integration ceiling. That is, at a certain point, more effort is spent on the connections than on new functionality and further expansion becomes cost prohibitive.
In the late 1990s, new integration technologies emerged that made it possible to “loosely couple” applications so that systems are no longer directly connected. Thus, changes in one system would not cause a ripple effect in any other systems. The most notable of these technologies were Message Oriented Middleware (MOM), Publish and Subscribe messaging, and Object Request Brokers. These technologies enabled companies to re-architect their conglomeration of systems into an architecture that allows them to expand in a cost-effective manner. Such technologies that address the problem of integrating existing systems with new systems in an organized, efficient, and economically scaleable manner can be referred to collectively as Enterprise Application Integration (EM). Four components of EAT are typically defined: Framework, Methodology, Approach, and Service Delivery. Frameworks depict and define relationships between Enterprise Architectures, such as Business, Conceptual, and Process Architecture, and Enterprise Application Integration. Frameworks also describe the points where work products defined in any methodology must interface. Methodologies define the semantics and notation describing rules governing and relationships between work products in the context of a Framework. Approaches solve problems associated with a specific objective by delivering work products that are methodologically, and therefore architecturally, consistent. Service Delivery is the instantiation of an Approach in order to produce those work products necessary to solve a real-world problem in an efficient, repeatable manner.
A desired method of transforming a disparate grouping of systems that were incrementally cobbled together into a stable, extensible, and affordable “system of systems” is to engineer it through detailed analysis and design. The software engineering discipline that addresses EAI and the underlying integration issue is known as Enterprise Architecture. Architectural engineers typically realize architectures by specifying the components to be used (hardware, software, network, etc.); depicting how the components fit together (where and when in the process); clearly defining the interfaces and boundaries between components; setting guidelines and standards; and determining the layers, services, dependencies, and abstraction levels.
These engineering efforts are typically broken down into several subordinate areas each of which is focused on a specific integration area. The subordinate areas can be referred to as Platform Integration, Data Integration, Systems Integration, Business Process Integration, and Business Integration. The areas of integration are hierarchical and their ease of implementation and value are generally inversely proportional. That is, the areas at the beginning of the preceding list have the greatest ease of implementation and the lowest value to an enterprise while the areas at the end of the list have the least ease of implementation and the highest value to an enterprise.
The types of architecture disciplines are closely aligned with the types of integration problems, with “Enterprise Architecture” serving as the over-arching architecture domain. The architecture disciplines that can comprise Enterprise Architecture are Business Architecture, Conceptual Architecture, Process Architecture, Technical Architecture, Information Architecture, and Application Architecture. Business Architecture enables the enterprise to define its desired future by systematically exploring and capturing its unique purposes, goals, strategies, and objectives; outlining the fundamental structures, processes and capabilities needed to fulfill its strategic intent; documenting these in ways that can meaningfully guide and influence the organization; and providing a framework for comparing and selecting competing business alternatives.
Conceptual Architecture enables the business to evolve its current inadequate automated systems into its ideal future systems by creating blueprints (targets) that outline the desired form of ideal future systems; identifying patterns and leverage points across multiple projects to expose hidden synergy; advocating frameworks that isolate change, increase flexibility, reduce cost, and speed construction; and building individual project blueprints that meet immediate needs while creating future opportunities.
Process Architecture enables the business to convert desired business concepts into clear, actionable solution specifications by documenting and clarifying the business requirements that must be fulfilled; defining conceptual solutions that convert business requirements into systems requirements; and clearly documenting the sequence and content of systems interactions required to create solutions.
Technical Architecture helps the business make wise choices in selecting and applying software tools and technologies by tracking industry trends in software technology, evaluating and recommending software that is applicable broadly across the enterprise, monitoring the evolution of key software used within the enterprise and advising on needed changes, and building consensus on the appropriate use of software technology within the business.
Information Architecture enables the enterprise to effectively organize and leverage its data resources by defining the key information assets owned by and available to the business; creating the processes, frameworks, and tools needed to fully leverage data as a corporate asset; and providing the technical expertise needed to apply and support database technology across the business.
Application Architecture defines the applications required to support the business functions and manage the information within the business environment by identifying candidate applications and their data stores needed to support the business function; based on all business, functional and system requirements, creating application definitions that describe what each of the applications should perform; identifying the business functions that are directly supported or performed by each application; and relating each application in the application architecture to existing systems.
For each type of integration problem area being addressed, a corresponding Enterprise Architecture discipline is typically needed. In some cases, a single Enterprise Architecture discipline can deal with multiple integration areas. Whether the various disciplines are assigned to a centralized Enterprise Architecture organization or are matrix managed is dependent on the constraints of the parent IT organization.